This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@sapiom/agent@0.14.0

Minor Changes

• 421439b: A defaulted field is no longer required at any depth in an input schema

  A step's published inputSchema listed a field as required even when it
  carried a Zod .default(), as long as the field sat inside a nested object, an
  array item, or a union/intersection branch. An AJV pre-gate then rejected a
  partial input for those fields while an entirely omitted input validated —
  so { opts: {} } failed where {} passed, contradicting the authoring guidance
  that a default makes a field omissible. A .prefault() field stayed required at
  every depth for the same reason.

  zodToJsonSchema now converts in Zod's io: "input" mode — the mode that
  describes what a caller may SEND — and runs the result through a new exported
  normalizeInputJsonSchema, which drops defaulted keys from required and
  strips additionalProperties: false on every schema node it can reach.

  If you call zodToJsonSchema directly, its output changes: a smaller
  required set, no additionalProperties: false from z.strictObject(), a
  .pipe()/.transform() described by its input type rather than its output
  type, and a schema containing a .transform() now converting successfully where
  it previously threw Transforms cannot be represented in JSON Schema. Every
  change is in the "what may a caller send" direction. If you need the
  value-a-parse-returns schema instead, call z.toJSONSchema(schema) yourself.

  Also:

  • stepInputContract / workflowInputContract return the same normalized
    schema the manifest publishes, so a displayed contract (a Run form, inspect
    tooling) agrees with what a pre-gate enforces.
  • @sapiom/agent-runtime's step-input pre-gate normalizes the manifest it is
    handed, so an agent deployed on an earlier version accepts a partial nested
    input without being redeployed. A .prefault() field still needs a redeploy —
    the older schema records no default keyword for it to key off.

@sapiom/agent-core@0.14.0

Minor Changes

• 5d18ba3: Expose all four backend trigger kinds from the local authoring MCP (SAP-3174).
  sapiom_dev_agents_schedule now accepts kind: "event" (+ eventType) and
  kind: "webhook" alongside schedule_cron / schedule_once. A webhook create
  returns the public hook URL, the shown-once signing secret, and the signing
  scheme in the tool result (HMAC-SHA256 over timestamp.eventId.rawBody, sent as
  X-Sapiom-Timestamp / X-Sapiom-Event-Id / X-Sapiom-Signature), and the
  description says when a webhook trigger fits versus an App Link /hook/*
  receiver (third-party senders cannot produce our HMAC). _schedule_inspect and
  _schedule_cancel describe every kind; the new sapiom_dev_agents_schedule_secret
  tool rotates, completes a rotation of, or revokes a webhook secret.

  @sapiom/agent-core gains the matching ScheduleKind members, the webhook /
  event fields on ScheduleSummary, CreateScheduleResult, and
  rotateScheduleSecret / completeScheduleSecretRotation / revokeScheduleSecret.

  Breaking (types only, @sapiom/agent-core): ScheduleFireRecord.scheduledFor
  is now string | null — an event or webhook fire has no occurrence time, so code
  that did new Date(fire.scheduledFor) must guard for null (or read
  fire.receiptId for those kinds). ScheduleSummary gains five required fields
  (eventType, publicId, secretVersion, graceUntil, revokedAt, all
  nullable) that the server always returns; hand-built ScheduleSummary values
  (test fakes, adapters) must add them. ScheduleKind widens to include "event"
  and "webhook", so an exhaustive switch over it needs the two new arms. No
  runtime behaviour changes for existing cron / one-off callers.

  The offline AUTHORING_INSTRUCTIONS fallback and the sapiom-agent-authoring
  skill gain a triggers paragraph teaching the same thing; the served-text change
  is version-gated on @sapiom/mcp >= 0.15 because older clients are never
  offered the new kinds.

Patch Changes

• Updated dependencies [421439b]
  • @sapiom/agent@0.14.0
  • @sapiom/agent-runtime@0.7.2

@sapiom/harness@0.17.0

Minor Changes

• 84f5767: Surface when a running Claude session needs the current Sapiom connection, prevent prepared sessions or tasks from launching after it changes, and expose MCP_CREDENTIAL_GENERATION_CHANGED as a retryable conflict.
• fefb4f8: Expose the shared credential-store path to authenticated local integrations and stop affected Studio-managed Claude sessions and background tasks when the current Sapiom connection is removed.
• cf3e872: Offer an explicit MCP session restart API and UI action when the Sapiom connection changes, and export McpSessionRestartUnavailableError for programmatic handling.
• b460c9a: Resolve linked agents from one tenant-scoped definitions list per poll instead
  of a by-id lookup per agent: definitions the signed-in account cannot see are
  never requested and show as unavailable in Studio. WorkflowInfo gains an
  optional, serve-time definitionAccess field (never persisted).

Patch Changes

• 7776065: Limit archive backfill to 200 conversations per maintenance pass. Keep source events while work remains or archiving fails, and retry at the next scheduled cleanup.

• 6b0b11f: Name the two Sapiom MCP servers by role in both offline fallbacks — "the local
  authoring server" and "the hosted capability server" — instead of by registration
  alias (SAP-3179).

  The two texts disagreed: the Studio prompt called the servers sapiom (hosted) and
  sapiom-dev (local), which is what Studio registers; the authoring primer called them
  sapiom (local) and sapiom-direct (hosted), which is what a plain Claude Code user is
  told to register. A Studio session reads both, so "use the sapiom alias to author
  agents" pointed it at the remote server the prompt had just said not to call while
  authoring. Aliases now appear only inside the two claude mcp add commands, which are
  unchanged. The Studio prompt also disambiguates the two same-named sapiom_authenticate
  / sapiom_status pairs, so a session signs in against the local server.

  Both digest pins move with the bodies. The paired backend content release
  (sapiom/Sapiom#4884) must adopt the same two bodies for the cross-repo pins to agree.

• 4b1ebc5: Keep overlapping Studio sign-in and sign-out transitions ordered while allowing a new sign-in to begin promptly after signing out.

• 0f28c4e: Prevent repeated exit-status broadcasts from deleting configuration regenerated during session resume, including sessions restored after restart or imported from history. Failed resume preparation also cleans up regenerated configuration.

• 7776065: Preserve the selected coding agent when launching a template from the new-session composer or template gallery, including bundled starters. Codex selections no longer start Claude Code sessions.

• Updated dependencies [6b0b11f]

• Updated dependencies [421439b]

• Updated dependencies [fefb4f8]

• Updated dependencies [5d18ba3]

  • @sapiom/mcp@0.16.0
  • @sapiom/agent@0.14.0
  • @sapiom/agent-core@0.14.0

@sapiom/mcp@0.16.0

Minor Changes

• fefb4f8: Expose the shared credential-store path to authenticated local integrations and stop affected Studio-managed Claude sessions and background tasks when the current Sapiom connection is removed.

• 5d18ba3: Expose all four backend trigger kinds from the local authoring MCP (SAP-3174).
  sapiom_dev_agents_schedule now accepts kind: "event" (+ eventType) and
  kind: "webhook" alongside schedule_cron / schedule_once. A webhook create
  returns the public hook URL, the shown-once signing secret, and the signing
  scheme in the tool result (HMAC-SHA256 over timestamp.eventId.rawBody, sent as
  X-Sapiom-Timestamp / X-Sapiom-Event-Id / X-Sapiom-Signature), and the
  description says when a webhook trigger fits versus an App Link /hook/*
  receiver (third-party senders cannot produce our HMAC). _schedule_inspect and
  _schedule_cancel describe every kind; the new sapiom_dev_agents_schedule_secret
  tool rotates, completes a rotation of, or revokes a webhook secret.

  @sapiom/agent-core gains the matching ScheduleKind members, the webhook /
  event fields on ScheduleSummary, CreateScheduleResult, and
  rotateScheduleSecret / completeScheduleSecretRotation / revokeScheduleSecret.

  Breaking (types only, @sapiom/agent-core): ScheduleFireRecord.scheduledFor
  is now string | null — an event or webhook fire has no occurrence time, so code
  that did new Date(fire.scheduledFor) must guard for null (or read
  fire.receiptId for those kinds). ScheduleSummary gains five required fields
  (eventType, publicId, secretVersion, graceUntil, revokedAt, all
  nullable) that the server always returns; hand-built ScheduleSummary values
  (test fakes, adapters) must add them. ScheduleKind widens to include "event"
  and "webhook", so an exhaustive switch over it needs the two new arms. No
  runtime behaviour changes for existing cron / one-off callers.

  The offline AUTHORING_INSTRUCTIONS fallback and the sapiom-agent-authoring
  skill gain a triggers paragraph teaching the same thing; the served-text change
  is version-gated on @sapiom/mcp >= 0.15 because older clients are never
  offered the new kinds.

Patch Changes

• 6b0b11f: Name the two Sapiom MCP servers by role in both offline fallbacks — "the local
  authoring server" and "the hosted capability server" — instead of by registration
  alias (SAP-3179).

  The two texts disagreed: the Studio prompt called the servers sapiom (hosted) and
  sapiom-dev (local), which is what Studio registers; the authoring primer called them
  sapiom (local) and sapiom-direct (hosted), which is what a plain Claude Code user is
  told to register. A Studio session reads both, so "use the sapiom alias to author
  agents" pointed it at the remote server the prompt had just said not to call while
  authoring. Aliases now appear only inside the two claude mcp add commands, which are
  unchanged. The Studio prompt also disambiguates the two same-named sapiom_authenticate
  / sapiom_status pairs, so a session signs in against the local server.

  Both digest pins move with the bodies. The paired backend content release
  (sapiom/Sapiom#4884) must adopt the same two bodies for the cross-repo pins to agree.

• Updated dependencies [5d18ba3]

  • @sapiom/agent-core@0.14.0

@sapiom/agent-runtime@0.7.2

Patch Changes

• 421439b: A defaulted field is no longer required at any depth in an input schema

  A step's published inputSchema listed a field as required even when it
  carried a Zod .default(), as long as the field sat inside a nested object, an
  array item, or a union/intersection branch. An AJV pre-gate then rejected a
  partial input for those fields while an entirely omitted input validated —
  so { opts: {} } failed where {} passed, contradicting the authoring guidance
  that a default makes a field omissible. A .prefault() field stayed required at
  every depth for the same reason.

  zodToJsonSchema now converts in Zod's io: "input" mode — the mode that
  describes what a caller may SEND — and runs the result through a new exported
  normalizeInputJsonSchema, which drops defaulted keys from required and
  strips additionalProperties: false on every schema node it can reach.

  If you call zodToJsonSchema directly, its output changes: a smaller
  required set, no additionalProperties: false from z.strictObject(), a
  .pipe()/.transform() described by its input type rather than its output
  type, and a schema containing a .transform() now converting successfully where
  it previously threw Transforms cannot be represented in JSON Schema. Every
  change is in the "what may a caller send" direction. If you need the
  value-a-parse-returns schema instead, call z.toJSONSchema(schema) yourself.

  Also:

  • stepInputContract / workflowInputContract return the same normalized
    schema the manifest publishes, so a displayed contract (a Run form, inspect
    tooling) agrees with what a pre-gate enforces.
  • @sapiom/agent-runtime's step-input pre-gate normalizes the manifest it is
    handed, so an agent deployed on an earlier version accepts a partial nested
    input without being redeployed. A .prefault() field still needs a redeploy —
    the older schema records no default keyword for it to key off.

• Updated dependencies [421439b]

  • @sapiom/agent@0.14.0

@sapiom/agent-studio@0.1.26

Patch Changes

• Updated dependencies [7776065]
• Updated dependencies [84f5767]
• Updated dependencies [6b0b11f]
• Updated dependencies [4b1ebc5]
• Updated dependencies [fefb4f8]
• Updated dependencies [cf3e872]
• Updated dependencies [0f28c4e]
• Updated dependencies [b460c9a]
• Updated dependencies [7776065]
  • @sapiom/harness@0.17.0

@sapiom/cli@16.0.0

Patch Changes

• Updated dependencies [7776065]
• Updated dependencies [84f5767]
• Updated dependencies [6b0b11f]
• Updated dependencies [4b1ebc5]
• Updated dependencies [421439b]
• Updated dependencies [fefb4f8]
• Updated dependencies [cf3e872]
• Updated dependencies [0f28c4e]
• Updated dependencies [b460c9a]
• Updated dependencies [7776065]
• Updated dependencies [5d18ba3]
  • @sapiom/harness@0.17.0
  • @sapiom/agent@0.14.0
  • @sapiom/agent-core@0.14.0

@sapiom/harness-desktop@0.4.7

Patch Changes

• Updated dependencies [7776065]
• Updated dependencies [84f5767]
• Updated dependencies [6b0b11f]
• Updated dependencies [4b1ebc5]
• Updated dependencies [fefb4f8]
• Updated dependencies [cf3e872]
• Updated dependencies [0f28c4e]
• Updated dependencies [b460c9a]
• Updated dependencies [7776065]
  • @sapiom/harness@0.17.0